AWS Site-to-Site VPN 接続のトンネルエンドポイントのライフサイクル制御を使ってメンテナンスを保留してみた

いわさです。

先日 AWS と別のパブリッククラウドの間でサイト間 VPN を構築していたんです。
その時見慣れない設定項目を見つけました。

トンネルのメンテナンス...調べてみると 1年近く前のアップデートでした。見逃しておりました。

サイト間 VPN ではトンネルのメンテナンスが AWS によって自動的に行われます。このメンテナンスは定期的に発生するのですが、そのメンテナンスのタイミングをコントロールするためのオプションとなります。
通常はひとつの接続の中で複数トンネルで冗長化構成を取ることで、接続のダウンタイムが最小になるようになっていますが、このトンネルのメンテナンスタイミングをユーザーがコントロール出来るようになります。

今回 VPN を構築した際にメンテナンスが発生するまで観察する機会がありましたのでついでにこのトンネルエンドポイントのライフサイクル制御機能を有効化してみましたので、ユーザーがメンテナンスを適用する流れなどを紹介します。

VPN を作成する際にトンネルのオプションで有効化する

今回は Azure と AWS の間で静的ルートでの VPN を構築しています。
AWS 側の VPN 接続はひとつでトンネルは 2 つ、Azure 側の VPN Gateway をひとつでローカルネットワークゲートウェイが 2 つです。以下の方法で作成しています。

AWS 側でトンネルを構成する際に次のようにトンネルエンドポイントのライフサイクル制御を有効化しています。

VPN 接続参照画面では次のように確認することが出来ます。

この時点では各トンネルにまだ保留中のメンテナンスが存在していないことが確認出来ます。

アップデート保留の通知きた

VPN を構築したのが1月20日です。
その 6日後の1月26日に早速メンテナンス通知が来ました。

が、何やらいつもと通知内容が違います。

タイトル：Update available for your VPN connection [AWS Account: 123456789012, VPN Connection: vpn-038781fb8d75357d6, Tunnel Outside IP: (35.76.43.22, 52.192.90.76)]

トンネルにアップデートが来たから、2月9日までにトンネル置き換え操作してくれぇという内容です。
それまでにユーザーが手動で操作をしなかったら AWS のほうでアップデートを自動に適用しちゃいますからね。とも言っています。

トンネルのプロパティを見てみると、保留中のメンテナンスが利用可能ステータスになっていることが確認出来ます。
なるほど、こんな感じで確認が出来るようです。

また、手動で適用しなかった場合に自動適用までの日数も表示されています。
ライフサイクルコントロールを有効化しても塩漬けには出来ずにタイミングを数日コントロール出来るような形みたいですね。

手動ですぐに適用すべきか悩んだのですが、この日は適用せずに様子を見ることにしました。

また、この通知は AWS Health からも確認することが可能です。

トンネル置き換えイベント発生したという通知きた

その翌日、1月27日の22:04と22:12に、なんとトンネルの置き換えイベントが発生したよという通知を受信しました。

Important notice about your AWS Account regarding VPN connections [AWS Account: 550669467088, VPN Connection: vpn-038781fb8d75357d6, Tunnel Outside IP: 35.76.43.22]

Important notice about your AWS Account regarding VPN connections [AWS Account: 123456789012, VPN Connection: vpn-038781fb8d75357d6, Tunnel Outside IP: 52.192.90.76]

なんと。
ライフサイクルコントロールを有効化していても自動置き換えされる時はされるみたいですね。置き換えとメンテナンスは概念が別なのだろうか...。

よくわかってないのですが、CloudWatch メトリクスでトンネルステータスを見てみると、該当時間にそれぞれのトンネルが一瞬ダウンになっているので置き換え発生しているようですね。

自動トンネル置き換え後も保留されたメンテナンスが残っている

ただし、トンネルの自動メンテナンスが行われた後も、マネジメントコンソール上では保留中のメンテナンスが残っているようでした。手動で適用しないとメンテナンス自体は適用されないのか...？

アクションメニューの VPN トンネルの置き換え、あるいは保留中のステータスのツールチップから置き換えメニューへ遷移することが出来ます。

VPN トンネルの置き換え操作は VPN 接続に対して行うアクションで、対象トンネルをひとつづつ選択する形となります。

対象トンネルを選択し、保留中のメンテナンスが存在している場合は次のようにメンテナンスを適用するかどうか選択することが出来ます。
明記されたドキュメントが見当たらなかったのですが、このチェックボックスを見る限りでは、どうやら必ずしも「トンネルの置き換え＝メンテナンス適用」というわけではないのかなと思いました。
そうすると、前述の自動置き換えの挙動とも辻褄が合います。

VPN トンネルの置き換えを開始すると VPN 接続ステータスが変更中となり、対象トンネルの保留中のメンテナンスがなくなりました。
また、最後に適用されたメンテナンスには実行時刻が設定されます。

少し待機すると VPN 接続自体は利用可能ステータスに復旧しましたがトンネルは少しの間ダウンしたままです。
シングルトンネルの場合はこのタイミングで VPN 接続のダウンタイムが発生しそうですね。

最終的にはトンネルもアップに戻りました。
トンネル置き換えとメンテナンス適用はトンネルごとに行う必要があるため、操作していないトンネルには引き続き保留中のメンテナンスが存在する状態となっています。

さいごに

本日は AWS Site-to-Site VPN 接続のトンネルエンドポイントのライフサイクル制御を使ってメンテナンスを保留してみました。

確かにメンテナンスの保留は出来たのですが、保留中にもトンネルの自動置き換えが発生する場合があるのと、保留期間には限りがあることがわかりました。
この挙動から、トンネルエンドポイントのライフサイクル制御機能は限られたシーンでダウンタイムが発生する可能性を少し緩和出来そうなものの、完全にコントロールさせるためのものではないことがわかりました。

推奨構成である複数トンネルを構成している場合であればお世話になる機会も少なそうなのですが、挙動について知っておくと良さそうです。